|
|
|
|
|
|
|
some of your users disliked the periodic requirements inquiries and surveys in previous projects, they really won't like the many questions that crystallize during the normal iterations in an object-oriented project. Uncooperative users will often give you inadequate use cases, increasing the risk of your application's architecture being faulty. In such situations, you'll want surrogate users. Surrogate users are users who are usually not as knowledgeable as the real users but can provide enough information for you to come up with a reasonable architecture. Business analysts make excellent surrogate users. Commercial developers need to find new samplings of users from more diverse geographic, economic, and cultural backgrounds to maximize the effectiveness of their use cases. |
|
|
|
|
|
|
|
|
In general, the more uncooperative your users are, the greater the risk of project failure. User nonparticipation in corporate environments is usually a symptom of political turmoil and/or lack of communication, but not always. If the users do not actively participate in the early architectural design of the system, you might as well update your resume. Not only will the system architecture be completely faulty, but also division and strife will develop among the project stakeholders, programmers will have to work around the clock in an attempt to find a miracle cure to help the project manager save face, and everyone will experience unnecessary stress. Users determine the system behavior, and without their participation, there is no architecture, and thus no scope, resulting in architecture deviation. |
|
|
|
|
|
|
|
|
Let's face it. Visual Basic has come a long way. The third version brought component-based development to the mainstream in ways that other languages could only dream of. Version four improved on that, but version five has made not only object-oriented design easier but also customizing and automating the development environment itself. Nevertheless, Visual Basic still does not fully support object technology, in the more popular sense of that paradigm. Implementation inheritance is not in Visual Basic, though delegation can certainly compensate for this lack. |
|
|
|
|
|
|
|
|
Simulating implementation inheritance in Visual Basic is not ideal. Some books and publications explain how to do some nice tricks with collections and classes to mimic implementation inheritance. However, attempting to make Visual Basic do what it was not designed to do can lead to performance issues and make the body of code difficult to read. Finally, because of the limitations in implementation inheritance, only a certain amount of polymorphism can be done in Visual Basic. However, interface inheritance and collections mitigate some of Visual Basic's shortcomings in this area. |
|
|
|
|
|